Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: fix deployments by build outDir changed to build and re-enabling artifact generation #293

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

immutable-pro
Copy link
Contributor

@immutable-pro immutable-pro commented Apr 30, 2024

  • ci: changing output directory for prod builds to build
  • ci: re-enabling artifact.zip generation

What's going on?

The machine where the website is deployed is periodically checking for the existence of an artifact.zip file, containing a build folder inside, with the required assets for the deployment.

A manual Github workflow has been added to trigger the release.

Copy link
Contributor

@owen26 owen26 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking great, thanks for putting it all together.

Only question before approve, is that is this going to be deployed to the one and only environment for kobot? Which is essentially production?

We might want to double check with FIRST to see if it's fine to override the current legacy site if that's the case.

Long term speaking it would be great to have this CI deployed to dev or uat environment, and have a prod deploy manually triggered.

@immutable-pro
Copy link
Contributor Author

Looking great, thanks for putting it all together.

Only question before approve, is that is this going to be deployed to the one and only environment for kobot? Which is essentially production?

We might want to double check with FIRST to see if it's fine to override the current legacy site if that's the case.

Long term speaking it would be great to have this CI deployed to dev or uat environment, and have a prod deploy manually triggered.

Yes, you are right. I thought about that too. It is a bit ...aggressive.

Before merging, I was going to suggest a "plan B" approach that consists of:

  • Use GitHub pages as a deployment preview.
  • Only generate artifacts.zip when a certain tag is created in GitHub, so we can control PROD deployments.

For that purpose, I would need admin access of the repo, as I can't see how GitHub pages is set up today, if at all.

@owen26
Copy link
Contributor

owen26 commented May 1, 2024

Yes, you are right. I thought about that too. It is a bit ...aggressive.

Before merging, I was going to suggest a "plan B" approach that consists of:

  • Use GitHub pages as a deployment preview.
  • Only generate artifacts.zip when a certain tag is created in GitHub, so we can control PROD deployments.

For that purpose, I would need admin access of the repo, as I can't see how GitHub pages is set up today, if at all.

Yes this looks like a great plan. The current site is totally static so GitHub Pages would be a good fit for deployment. It might also has the extra benefit for not being blocked by our VPN cuz I think Netlify on the other hand is blocked.

For production deployment yes we can either generate artifact when a tag is generated. (aka. feat or fix commit involved)

Alternatively, we can also have the artifact build workflow targeting on: workflow_dispatch trigger on github, so we can get a manual "Run workflow" button to make prod deployment.

@immutable-pro immutable-pro marked this pull request as draft May 13, 2024 09:45
@immutable-pro immutable-pro marked this pull request as ready for review July 2, 2024 16:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants