I am doing this course on HTML, CSS, and Javascript for Web Developers on Coursera, as I am new to all this, and I have stumbled upon something that I think is very old information in the course, and not working anymore with the same tools as they have changed over time. So in this course we have the GitHub pages tool, which at that time could be used simply via the "deploy" button. Right now, the GitHub pages tool is disabled unless you create a branch, and it offers this GitHub Actions option under Build and Development, from where you can choose different workflows. By choosing any of them, you get the site deployed, but upon entering it, it gives 404 error. From my understanding, what's missing is the index.html file. How can you use the GitHub Actions tool to also have the index.html file and get rid of the error?
I have tried deploying from a branch, but I am missing valuable information on how to make that work.
Related
I am writing a scalajs app (though this is not specific to scalajs), and I would like to be able to use it simply by linking to a URL from anywhere. Previously, I was putting the compiled javascript in my github repo, and then linking it using https://cdn.jsdelivr.net/gh/, but I want to build the javascript in CI. What is a place (preferably free) that I can upload to, and then be able to link to specific commits? Should I just shell out for an AWS S3 bucket? Should I make an NPM prerelease for every commit? I could also push to a different branch within the github action, and then use https://cdn.jsdelivr.net/gh/, just like making github pages. I feel like there should be a blessed way to do this, but I don't know what it is.
I want to upgrade our GitHub workflows with accessibility linting based on WCAG 2.1. If it's possible I want to define the level too like AA.
I don't want to run a full test on a website, only make a quick linting on the pull requests. The whole site testing will be the next step, but now I want to focusing to pull requests only.
I checked pa11y and several repos based on this, but as I see this solution can test only a working website and not a pull request.
Is there any working solution for this?
I am not by any means a sophisticated github user. I have learned the minimum handful of commands needed to add, commit, and push my project code to the public github.com repository. So far it's been working fairly well... until today when I tried to create a new release (my third).
For some reason, when I try to publish my new release, I get the message
Tag could not be created. Pre-receive hooks failed.
I have never seen this message before.
I have tried various different tag names; I have tried logging out and back in again; I have tried pre-tagging on my local disk copy of the repo; I have pushed and pulled (both ends are up to date). This about exhausts my repertoire of things to try :-(
As a relative n00b I find this message incredibly opaque (sigh). I have tried googling for it, but quickly got in over my head -- most of the hits I found were discussions about people setting up their own networked repos and installing or tweaking their own custom "pre-receive hooks", whereas I am just a dumb user of github.com apparently struggling with whatever "pre-receive hooks" they have installed (?). If anyone can at least point me in the right direction I'd be most grateful.
Make sure you select the tag version in the dropdown. The GitHub form will let you submit when this field is blank, but it will always display the mentioned error message. (You do not need a 'v' prefix.).
The latest Github form makes this more cryptic by having a dropdown titled 'Tag:Choose or Create" that hides the fact that this field is both required but not set.
Latest Github Form
Older Github Form
In a GitHub context, I have seen that error message in this issue
It could be a tag naming convention issue.
The GitHub release documentation recommends (enforces?) a tag following the semantic versioning naming scheme: vX.Y.Z.
As shown here, try vx.y.z.
Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
I'm using Travis-CI with GitHub.
I would like to know if is possible to reset the build number and/or delete the related Travis page.
I tried to delete my repo on GitHub but this is not affecting the related Travis page.
Even if I create a new repo, with the same name of the previous, the build number starts from the previous one, and the builds are linking on 404 on GitHub. I know that isn't a big issue, but I would like to keep consistent all my solution.
Unfortunately we don't have a way to delete repositories or builds. If any private data has been exposed, you can always email us to have the logs stripped.
We are working on a way to archive repositories, which basically means that they'll be hidden until a new build is run, see the issue for more information on that.