The Publish API enables you to publish your project externally from Holistics, facilitating seamless integration with CI/CD workflows. By doing so, it leverages the full potential of an as-code approach, enhancing both automation and scalability.
This capability is particularly beneficial in scenarios such as:
Publish the latest update after merging PR into the master branch by integrating Publish API with the CI/CD workflow.
Publish the latest update after new changes are pushed to master branch.
We just attempted the feature as recommended with github actions and believe we got it working, thank you so much for this, we’re really excited!
Once small thing we noticed though, when we used the proposed action flow as described in the post above, a PR being merged to master in github seemed to trigger 2 jobs, one for both the PR closed event (which is actually listed as running against the source branch rather than master when you go to the actions tab) and the other for the push of the new commit to master. A couple questions on that:
Is there any concern about the duplicate jobs creating an issue (ex. a race condition or something else), or is this relatively safe?
If we switch to JUST trigger on pushes to master branch, are there any events that this is likely to miss that the pull_request event would catch? What’s the reason for having both triggers?
Is there any concern about the duplicate jobs creating an issue (ex. a race condition or something else), or is this relatively safe?
They are relatively safe, both of these jobs deploy from your latest commit on the branch master. However, having duplicated jobs might bloat your job queue. Therefore, I would recommend you deduplicate these jobs.
If we switch to JUST trigger on pushes to master branch, are there any events that this is likely to miss that the pull_request event would catch? What’s the reason for having both triggers?
I apologize if this example creates confusion. For the GitHub Action config, please choose one that suits your setup. The key is to use our @holistics/deploy-aml action. A trigger for pushes to the master branch should suffice for deploying after merging your PR.
So in your case, just triggering on pushes to master branch is enough. It will run fine and deduplicate the job as well.
Let me know if you have any questions, and thank you for using and leaving feedback. Looking forward to hearing from you!
Amazing, thank you! One more question: is the “Checkout repository” step necessary in the workflow, or is that just an example of how you can add the Deploy step to an already existing workflow? I did take a look at the code and I’m not seeing much in there that would rely on it, plus as you said, it would always deploy the latest commit on the master branch anyways. Apologies for the questions, github actions is not an area that I’m super familiar with! I would normally be down to test stuff like this out instead of asking but deploying to production seems like an area I probably shouldn’t mess around with too much
No worries, happy to help! The “Checkout repository” step (actions/checkout) is only necessary if your workflow needs access to your code. If you’re just using our @holistics/deploy-aml and not interacting directly with the code in the workflow, you can likely skip it.
Let me know if it helps and feel free to let me know if you have any other concerns. Looking forward to hearing from you!
In order to unify the Publish concept with the Holistics App, we will rename the GitHub action to @holistics/publish-aml within today. Please help update your action config to run it correctly. We apologize for any inconvenience this might have caused.
