Add Github Action Support for pkg updates

[adilanchian]

Currently, out GitHub Actions support checking the cmd/* folder, which houses all our functions. We have another folder, pkg/* that includes all the publicly shared methods/types/helpers that also need to be tagged when pushed to master.

This feature is to implement this check Action as part of the pipeline if there is a version change:

1. Change pkg file
2. Update version
3. Merge master
4. Tag with latest

This needs to happen before the GCloud deployment process as the functions could potentially utilize these changes.

[adilanchian]

@brettski Let me know if this makes sense and if you are open to taking this on!

[brettski]

Hi @adilanchian. Yeah, I will do this, please assign it to me. I am sure I will have questions once I dig in. :)

[adilanchian]

Done :). Thanks!

[brettski]

@adilanchian What is the tag structure/format for the packages in the /pkg folder?

[adilanchian]

Tag structure should be pretty similar to functions structure:

pkg/{PkgName}/v1.0.0-beta.bla

Feel free to go check out one of the tagged versions in the repo just in case :)

[brettski]

FYI, the requirement to have the pkg folders tagged prior to the deploys complicates things a bit based on how the workflow is currently designed. I can't simply throw a check in the current files as I worry it may cause a race condition. It's not the proper approach.

I have an approach on how to refactor it all but its going to take a bit of time to work through and especially test. I wanted to make sure you knew @adilanchian.

[adilanchian]

@brettski thanks for the heads up here.

Ya I had a feeling this could happen and thats totally fine! The workaround, while not great, is to commit pkg changes first, pr into master and then tag. After, All the other functions need to be rev-ed using that new version and then pushed to master where the actions can currently run.

If you have a way to simplify this, that would be sweet! I was also thinking yesterday it might be cool to have a manual trigger where we can redeploy all the functions at any time if we need to. Thoughts?

[brettski]

Thinking out loud here. Instead of us checking for the cmd/functionName/** for changes to deploy, what if we specifically look for cmd/functionname/.version for changes to trigger a deploy? This could provide a little more control on when the deploys go. Though I guess this does mean that the code in the repository could get out of sync with the .version file which could bad thing.

I could also build a interim GitHub actions file for each of the packages so they are automatically tagged when their .version file is update on push. All the logic is there, so it will go together quick. I guess it all comes down to how much of a pain it is making an additional PR currently. Regardless function changes will always need to be revved and auto incrementing function version is a bit premature for this project imo.

Let me know what you think.

[brettski]

Leaving a note that I haven't forgotten about this event though its been over a month of no response.

[adilanchian]

Hey @brettski thanks for the follow up here and sorry for the late reply!

Tomorrow on stream I'm going to be going threw all the Grüvee work and triaging things for Hacktoberfest!

Will make sure to follow up on this